Latest vulnerabilities for vendor "apache software foundation"

CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:N/R:X/V:X/RE:X/U:X

Last updated 4 September 2026

1 / 2

Source: Ubuntu

First published (updated )

CVE-2026-66755

Apache Software Foundation Axis2/JavaApache Axis2/Java: deserialization of untrusted Data

Risk 90

Severity

9.8

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Deserialization of Untrusted Data (CWE-502) in the Tribes-based clustering component

in Apache Software Foundation Apache Axis2/Java through 2.0.0 on Apache Tomcat

(only when Tribes clustering is enabled, which is off by default) allows an

unauthenticated remote attacker with network access to the clustering port to

execute arbitrary code via a crafted serialized Java object delivered to the cluster

channel and deserialized in

org.apache.axis2.clustering.tribes.Axis2ChannelListener#messageReceived. Users are

recommended to upgrade to version 2.0.1, which fixes this issue by removing the

clustering feature entirely.

First published (updated )

CVE-2026-66713

oss-secCVE-2026-66713: Apache Axis2/Java: deserialization of untrusted Data

Severity: low

Affected versions:

- Apache Axis2/Java through 2.0.0

Description:

Deserialization of Untrusted Data (CWE-502) in the Tribes-based clustering component

in Apache Software Foundation Apache Axis2/Java through 2.0.0 on Apache Tomcat

(only when Tribes clustering is enabled, which is off by default) allows an

unauthenticated remote attacker with network access to the clustering port to

execute arbitrary code via a crafted serialized Java object delivered to the cluster

channel and deserialized in

org.apache.axis2.clustering.tribes.Axis2ChannelListener#messageReceived. Users are

recommended to upgrade to version 2.0.1, which fixes this issue by removing the

clustering feature entirely.

Credit:

liuhuajin of Huawei (finder)

References:

https://github.com/apache/axis-axis2-java-core/commit/e6f53b230bddcb40577c84ff290ba51e7265fa15 https://axis.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-66713

First published (updated )

https://seclists.org/oss-sec/2026/q3/290

Apache Software Foundation ActiveMQ 6.3End of life details

Latest version: 6.3.2

First published (updated )

EOL-apache-activemq-6.3

oss-secCVE-2026-59173: Apache Traffic Server is vulnerable to stalled HTTP/2 flow-control

Apache Traffic Server is vulnerable to stalled HTTP/2 flow-control.

CVE: CVE-2026-59173 - DoS vulnerability in HTTP/2 via stalled flow-control conditions

Severity: important

Reported By: Okta Red Team

Vendor: The Apache Software Foundation

Version Affected: ATS 9.0.0 to 9.2.13 ATS 10.0.0 to 10.1.2

Mitigation: 9.x users should upgrade to 9.2.14 or later versions 10.x users should upgrade to 10.1.3 or later versions

Reference: https://www.cve.org/CVERecord?id=CVE-2026-59173

First published (updated )

https://seclists.org/oss-sec/2026/q3/162

Apache Software Foundation Spark 4.2End of life details

EOL

Jan 11, 2028

End of life: 1/11/2028, Latest version: 4.2.0

First published (updated )

EOL-apache-spark-4.2

Apache Software Foundation Apache CamelApache Camel: Camel-Cometd: Inbound Bayeux message headers are mapped into the Exchange without a HeaderFilterStrategy, allowing unauthenticated clients to inject Camel control headers

Risk 86

Severity

9.8

Input Validation

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Improper Input Validation vulnerability in Apache Camel Cometd Component.

The camel-cometd component maps inbound Bayeux (CometD) message headers into the Camel Exchange without applying a HeaderFilterStrategy. CometdBinding.populateExchangeFromMessage copies the entire ext.CamelHeaders map supplied by the CometD client directly onto the Camel message (message.setHeaders), so any header name - including Camel-internal control headers such as CamelHttpUri, CamelFileName or CamelJmsDestinationName - is accepted unmodified. Because a CometdComponent installs no Bayeux SecurityPolicy by default, any client that can complete the Bayeux handshake against the CometD endpoint can publish such a message without authentication. An attacker can therefore inject arbitrary Camel control headers that influence the behaviour of downstream producers in the route (for example redirecting an HTTP producer, changing a file name, or overriding a JMS destination); the injected headers also persist across internal direct, seda and vm hops. The concrete downstream impact depends on which producers the route uses. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.

Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix implements a HeaderFilterStrategy in the camel-cometd binding (a long-standing TODO in the code) that filters the Camel header namespace case-insensitively on inbound mapping, so client-supplied Camel / camel headers are no longer copied into the Exchange. For deployments that cannot upgrade immediately, strip the Camel control headers from inbound CometD messages before they reach any downstream producer (for example removeHeaders('Camel') and removeHeaders('camel') at the start of the route), and install an explicit Bayeux SecurityPolicy on the CometdComponent so that only authenticated clients can publish.

First published (updated )